[Previous] [Next] [Index]
[Thread]
RE: N$ SSL vs M$ PCT
<Sender composed mail containing characters not in the US-ASCII set.>
<These characters have been transformed into a printable form.>
Hi John -
Thanks for your thoughts. The feedback's important. The folks here =
have also given it some thought, and Dan's merged their comments with =
his own, and spelled out below.......
Rick
---
Mr. Hemming discusses four important distinctions between PCT and SSL,
concluding in each case that the related improvement in PCT is
irrelevant. We beg to differ.
The first issue he raises is that of efficiency. Perhaps Mr. Hemming
feels that a reduction in the number of round trips in an
authentication protocol is unimportant, but extra rounds can
translate into multiple-second delays for clients and substantial
load increases for servers--hardly a trivial matter.
The issue of separate keys for encryption and MACs is also far more
important than Mr. Hemming suggests. Unfortunately, it is not always
possible for strong encryption to be used. (For example, France
outlaws it compeletely, unless explicit escrow provisions are made.)
In such circumstances, when message privacy is not at all
guaranteed, there are still many activities that one might like to
pursue semi-publicly over the Net--if one can be sure that
adversaries cannot tamper with sent and received messages for their
own benefit. Certainly, digital signature of every message would
solve that problem, and Microsoft's STT uses precisely that approach
in the realm of transactions, where integrity and assurance of
origin over the long term are crucial. However, for simpler
tasks--such as, say, a sequence of database queries--it is far more
efficient, and no less secure, to establish a session with inexpensive
MAC-based message integrity (even without privacy).
Similarly, Mr. Hemming's comment that the verify-prelude step is
unnecessary because the use of weak cryptography should be banned
anyway completely ignores the unpleasant reality that weak
cryptography is in many circumstances simply unavoidable. Moreover,
weak (or even non-existent) cryptography is perfectly sufficient for
many functions for which privacy is simply not important, as long as
authentication and message integrity are guarantee. And it is
simply unrealistic to expect clients and servers to refuse all
connections, even for completely open, non-secret operations, unless
strong privacy conditions are met. For this reason, the tools that
PCT provides to secure both privacy and authentication in a world
containing weak cryptography are essential, and one of those tools
is ex post facto verification of the cryptography specification
negotiation. In fact, SSL version 3 offers exactly such a
feature, in its new "handshake hash" field; however, SSLv3's complete
backward compatibility with SSL version 2 renders this integrity
check completely ineffective, since adversaries can simply tamper
with negotiated version numbers as well as key lengths.
Mr. Hemming also misses the point of the security hole in SSL's client
authentication. It is true that client authentication requires a
digital signature; the problem is that SSL allows an adversary to
set up a new session for which the client's required signed response
is *identical* to the signed response required for a particular
session-in-progress. Hence, by playing man-in-the-middle in the
(broken) session-in-progress, the adversary can obtain the signature
required as a response in the new session. More significantly, this
new session may be one using strong cryptography, whereas the broken
session-in-progress used weak cryptography. Hence the server's
ability to restrict certain private operations to highly secure
sessions (those using strong cryptography) is negated.
Finally, Microsoft's purpose (and, I hope, everyone else's) is to
allow Internet activities to be made as secure as possible. The
security problems in SSL cannot be ignored, or they will come back
to haunt its implementers as surely as the SSL implementation
problems we have seen so far --except that recovery from a protocol
flaw is far more difficult than a simple bug-fix. In releasing PCT
to the public, we are proposing a protocol that we hope will lack
such time-bombs; to that end, we encourage all who have an interest
in Internet security to root through the protocol in excruciating
detail, looking for bugs, holes or possible improvements, and to
send suggestions and criticisms to pct@microsoft.com. We look
forward to your feedback.
Daniel Simon
----------
From: "John Hemming CEO MarketNet" <JohnHemming@mkn.co.uk>
To: <www-security@ns2.rutgers.edu>
Subject: N$ SSL vs M$ PCT
Date: Sunday, October 01, 1995 8:37PM
Having found that Micro$oft have produced a standards document
about their alternative to SSL I was interested in comparing it to
that written by Net$cape.
The big question in my view is why did they produce a new
proposal is it:
a) Because they have found major flaws in the SSL protocol
and wish to correct these (note the protocol not the implementation)
or is it
b) Because M$ want to "own" the Internet Security Software market
and take the initiative off N$ who, notwithstanding their problems with
implementation, have produced a working system.
My personal view is that b) is the case.
Comparison
I have compared
SSL V3 <draft-hickman-netscape-sl-01.txt> (available at www.netscape.com)
PCT http://www.microsoft.com/windows/ie/pct.htm <draft-microsoft-PCT-91.txt=
>
Both have status of Internet Draft.
I have implemented SSL V2 in a browser =
(ftp://193.119.26.70/mktnet/pub/horse.zip)
and a server (https://alpha.mkn.co.uk/)
I have not implemented and do not intend implementing PCT=7F
Both SSL V3 and PCT now involve a vast number of different alternatives
for Ciphers most of these alternatives do not help in any practical sense
and I have not compared the lists.
PCT allows for supporting SSL as well by using a bit in the SSL version num=
ber
to indicate PCT. This means that servers can support both protocols. Clien=
ts
cannot as the first message is sent by the client and there is no provision=
for
SSL/PCT negotiation.
Both PCT and SSL start with an initial session (GET or POST in wwwland) whi=
ch
establishes a master key and allow continuations of that key in later sessi=
ons.
M$ use the following arguments in support of PCT:
1. it is simpler.
PCT uses longer messages with more fields in them. It cuts out the final
SERVER-FINISHED and CLIENT-FINISHED messages. It puts some of the
data in SSL into other records. I quite like the verification in the =
CLIENT-FINISHED
message which means that bad implementatations crash out at that point rath=
er
than putting rubbish into the higher level protocol. However, I consider t=
hat
in essence there is no real difference. I, therefore, disagree with M$.
2. Message authentication uses different keys to the encryption keys. How
this helps, apart from making implementation harder, I cannot quite fathom.=
We
should not be using this secure channel protocol for proper message =
authentication
only. The MAC (Message Authentication Code) is not what I would use for
authentication from a legal and contractual background. I prefer =
Digitally Signed
Instructions.
3. They say there is a security hole in SSL's client authentication.
When the initial session establishing a session key uses (for example) 40 b=
it
encryption. It does mean that subsequent sessions are also essentially just=
as
insecure. This is the case for PCT and SSL. However, client authenticatio=
n
in SSL uses a digital signature using the client's private key. To get hol=
d of
this requires something more than simply being man in the middle. I think =
M$
are well out of order on this one.
4. They introduce a verify prelude field to make sure that the cipher type
and other negotiations have not been tampered with. I suppose this is a
fair if disingenuous point. If a "man in the middle" is tampering with you=
r
negotiations to make sure that you use a low level of encryption so that it
can be cracked then your implementations should not be using such
crippleware and cypherpunks will have cracked it ages ago.
There is a point that should be made that servers and clients should really
indicate the encryption cipher being used. Both my client and server do.
So in essence M$ make 4 arguments. Two are IMHO wrong. One is
irrelevant from a commercial perspective and the other one does not matter.
In the end N$'s version is working. M$ are probably coding like mad.
The final formula to determine the result may be
if (M$>N$) SSL+=3DPCT;
where M$ and N$ are measured in US Dollars.
(MarketN#t is a UK company independent of both M$ and N$ although=7F
N$ were helpful in debugging the interoperability of my early essays into
SSL for which I am grateful.)